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(54) Client/server protocol for proving authenticity 



(57) A protocol for establishing the authenticity of a 
client to a sender in an electronic transaction by encrypt- 
ing a certificate with a Icey known only to the client and 
the server. The trust of the sefVer, if neces)$ary. can be 
established by a public key protocol. The client gener- 



ates and sends over a communications channel a mes- 
sage containing at least a part of a certificate encrypted 
with the server's public key or a secret session key The 
server receives and processes the message to recover 
at least part of the certificate, verifies and accepts It as 
proof of the cftents authenticity. 



\ 



CM 
< 



o 

00 

o 

Q. 
UJ 



Prtnted b/ Jouvo. 75001 PARIS (FR) 



EP0 807 911 A2 



Description 

The invention relates to a protocol for one party to 
an electronic transaction, as lor exannple a client In a 
client-server transaction, to prove its authenticity to the 
other party of the transaction. 

BACKGROUND OF THE INVErJTiON 

Client-server systems provide electronic access by 
the client to data, information, accounts and other ma- 
terial stored at the server. In financial transactbns, the 
system provides a client electronic access to accounts 
and financial resources. 

In a client-server transaction, the client is required 
to prove to the sen/er that it is an authentic client, and 
not some impersonator or other unauthorized party. Pro- 
tocols are known by which a client proves to a server its 
authenticity, while at the same time it does not reveal 
Information that could be misused by a third party. 

A standard well known protocol for proving authen- 
ticity involves public-key cryptography. The client estab- 
lishes a public key/private key pair and provides the pub- 
lic key to the server. In a transact kxi. to prove its authen- 
ticity to the server, the client forms a digital signature 
with its private key on a time-varying message, and the 
server verifies the digital signature with the client's pub- 
lic key. The time-varying message, which may be a 
timestannp or a challenge supplied by the server, is dif- 
ferent in each instance. This message, when checked 
by the server, provides safeguards against a third party 
impersonating the client by simply replaying copies of 
previous signatures of the client that the third party has 
intercepted or otherwise acquired. 

In the standard protocol described above, the serv- 
er trusts that the public key belongs to the client, i.e.. 
that the client is in fact actively involved in the transac- 
tion because it is presumed that only the client knows 
the private key and can form valki digital signatures. A 
convenient way to establish trust h a public key is to use 
a certificate. This is accomplished by a certifrcatk>n au- 
thority issuing public-key certificates signed with the cer- 
tification authority's private key, which thereby asserts 
to the server that the client's publk; key is a valid public 
key issued by or registered with the certification author- 
ity. Assuming the server trusts the certification authori- 
ty's public key, then it trusts the clienrs certificate, the 
client's public key and ultimately the client's authenticity. 

With typical public-key cryptosystenr\s, it is compu- 
tationally expensive to form digital signatures because 
of the need to perform an exponentiatkxi operation. In 
some electronic Iransactrans, for example, those involv- 
ing a smart card client where the computational capacity 
is limited, the standard protocol using a digital signature 
is computationally expensive and is therefore a signifi- 
cant burden. ' — : 

Seller and Yacobi. in an article entitled Tully- 
Fledged Two-Way Publk; Key Authentication and Key 



Agreement for Lx>w-Cost Terminals* ELECTRONICS 
LETTERS, May 27. 1993. Vol. 29. No. 11, at pages 
999-1000, describe a protocol that provides for less on- 
line computation on one side of the protocol. In this pro- 

5 tocol authentication of the server by the client is carried 
out by the server sending a random challenge with an 
expected ■colour', structure or format, to the client for 
verification by the client. Authentication of the client by 
the server is achieved by the client sending to the server 

10 Hs identity, public key, certificate and a signature on the 
random challenge for verification of the certificate and 
the signature by the server. The protocol is described 
as being useful where one side of the interaction is a 
low-cost customer device such as portable telephones, 
home banking terminals, smart cards and notebook 
computers. 

Other protocols are known tor establishing the au- 
thenticity of a client to a server. Client authentication 
protocols such as those based on secret-key cryptogra- 

20 phy exist, but often have the limitation that the server 
must be on-line, or the server must store a key which 
can be used to impersonate arbitrary clients. In Cellular 
Digital Packet Data systems, a client authenticates itself 
to a server by sending a one time password encrypted 

2S with a Diffie-Hellman shared key, and the server returns 
a new password for the next session. Again, the server 
must be on-line or the client must share a different pass- 
word with each server, which can be inconvenient. 

30 BRIEF DESCRIPTION OF THE INVENTION 

A protocol that is less computationally expensive for 
a client but achieves similar goals as the standard pro- 
tocol is used to develop a server's trust ri the client. In 

55 this protocol, a certificate provided by a trusted cert'rfi- 
cation authority to the client is encrypted with a key 
known only to the client and the server or the public key 
of the server. The client forms no digital signature. Since 
only the client and the server it trusts have access to the 

40 certificate, the certificate itself is proof of the authenticity 
of the client; This protocol is particularly useful in client 
devices having small computational capacity, e.g., a 
smart card. 

Additional interactive protocols are disclosed 
45 whereby messages are exchanged between client and 
server to establish authenticity of both the client and the 
server as well as protocols wherein only a portion of the 
client's certificate is encrypted. Moreover, the certificate 
can include a one way function, such as a cryptographic 
so hash function of a secret value or a root of a hash tree 
of secret values for protection against the certification 
authority or unauthorized servers, respectively. 

A still furthermore general protocol involves a user, 
which may be an individual, a computer or some other 
55 entity, connected to a verifier by way of an encrypted 
communicatk^ns channel such that the user can confi- 
dentially deliver to the verifier information essential to 
verify the message. 
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DESCRIPTION OF THE DRAWINGS 

Figure 1 schematicaify illustrates the components 
of a smart card; 

5 

Figure 2 illustrates the connponenis of a sender; 

Figure 3A is a flow diagram showing the procedure 
for generating messages by a client to prove its au- 
thenticity to a server; w 

Figure 3B is a flow diagram showing the processing 
at th e server of messages sent by a client to authen- 
ticate the client: 

75 

Figure 4A is a flow diagram illustrating an interactive 
embodiment of the hvention where the server 
sends a copy of its certificate to a client; 

Figure 4B is a flow diagram illustrating an interactive 
embodiment of the invention where the server 
sends a copy of its certificate and a time-varying val- 
ue to the client: 

Figure AC is a flow diagram illustrating an interac- ss 
five embodiment of the invention where the server 
sends a time-varying value to the client; 

Figure 5 is a flow diagram illustrating an interactive 
embodiment of the invention where a client is sent 30 
a rhessage signed by the server; 

Figure 6 is a partial flow diagram illustrating a vari- 
ation in the messages generated by the client; 

S5 

Figure 7 is a partial flow diagram illustrating a ver- 
sion of the invention where a client's certificate is 
sent directly to a server; 

Figure 8 is a partial flow diagram of Figure 5 modi- 40 
fied so that only part of the client's certrficale is en- 
crypted; 

Figure 9 is a partial flow diagram of Figure 6 rrKxJi- 
fied so that only part of the client's certificate ts en- <s 
crypted; 

Figure 10 is a partial flow diagram of Figure 7 mod- 
ified so that only part of the client's certificate is en- 
crypted; so 

Figure 11 is an illustration of a hash tree which may 
be used to prevent misuse by a server; and 

Figure 12 illustrates a still further flow diagram of ss 
essential elements of a system having a more gen- 
eral protocol but which may have features of other 
embodiments disclosed herein added thereto. 
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DESCRIPTION OF THE PREFERRED 
EI\1BODIMENTS 

The specific description of the invention is set forth 
in the environment of a snnart card client. However, the 
invention Is not limited to a smart card client since the 
disclosed protocols are applicable to client/sender sys- 
tems in general, and In particular clients having low com- 
putational capacity such as portable telephones, note- 
book computers and home banking terminals. In an 
even more general manner the disclosed exemplary 
embodiments as described later can involve a user, 
which can be an individual, a computer or some other 
entity, which is connected to a verifier, which can be a 
client, a server or some other entity, via an encrypted 
communications channel whereby the user can confi- 
dentially deliver to the verifier Infornnation essential to 
verify the message. 

A smart card includes a microchip containing a 
processor and memones to hold programs and data. 
Figure 1 illustrates a smart card 1 comprising a proces- 
sor 2, an erasable progranrunable read only memory 
(ERROM) 3, programmable read only menDory (PROM) 
4, random access memory (RAM) 5. input/output (I/O) 
port 6, number generator 7, clock B and power source 
9. PROM 4 holds the card operating system and RAM 
5 holds temporary results of calculations. EPROM 3 
holds the certificate for the card. This certrf icate for the 
card, unlike the usual public key certificate, need not in- 
clude the public key of the client since authentication of 
the client by the server does not rely on the public key 
of the client A cache of pubic keys of one or more serv- 
ers may also be stored in PROM 4 or EPROM 3. Number 
generator 7 provides random seed numbers to the proc- 
essor for generating secret session keys. Ckx;k 8. con- 
ventkxial and well known in the art. is used for generat- 
ing a timestamp and for verifying a received tinnestamp. 
Clock 8 is optkxial where the server's timestamp or time- 
varying value ts used by the client to provide a time-var- 
ying value or where a challenge procedure is followed. 
Power source 9 is a battery when a card has a ck5ck. 
OthenMse, power may be supplied by an external 
source or a server. I/O terminals 6 provide a means for 
external communicatkxis. 

The public key of a trusted certification authority 
may be stored in PROM 4 or EPROM 3. PROM 4. or the 
RAM 5 if non-volatile, may have a section for storing cer- 
tificate revocaton lists (CRLs). Such a list woukj include 
a list of servers whose certificates have expired or been 
revoked. This list woukJ be provided by signed and dat- 
ed messages from the trusted certification authority ei- 
ther directly or indirectly while in a communicating rela- 
tionship with a sender Reference to the list during the 
initial stages of the-protocol will indicate whether the 
transaction being initiated is with a valid server or with 
one holding a revoked certificate, and thereby whether 
a received server's certificate is to be verified. 

The card manufacturer initializes the smart card us- 
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ing conventional techniques. PROM 4 is loaded with an 
operating program to be executed by processor 2, clock 
8 Is set (or an initial time-varying value, e.g., a sequence 
number or a timestamp is set in one of the memories 
when a clock is not usecO and the certificate associated s 
with the card and the trusted certificatton authority's 
public key are k>aded into the memories. Optionally, 
sender public keys and CRLs are also loaded into the 
menrx>ries, 

A server 40 as illustrated in Figure 2 includes a proc- io 
essor 60, a facility for generating a time-varying value 
or timestamp 42, input/output port 63, and a memory 61 
for holding the operating program for the processor, the 
private key PRIVserv associated with the server's pub- 
lic key PUBqerv l^e public key PUBj^ca ^r^st- is 
ed certification authority that signed the client's certifi- 
cate. In addition, memory 61 may hokJ a certificate rev- 
ocation list (CRL) and a certificate (CERT-S) for its pub- 
lic key. The facility for generating a lime-varying value 
42 may comprise a ckxjk for generating a timestamp or 20 
other means for generating a time-varying value. The 1/ 
O port 63 provides an interface between the processor 
of the server and external entities. 

Figure 3A illustrates the processing by a client for 
generating and sending messages to a server for use 25 
by the server to prove the client's authenticity. A client 
at 101 generates or provkJes a time-varying value (TS). 
This may be a timestamp or other value which changes 
with time. The client also generates a random secret 
session key (KSS) at 1 02 employing a number genera- 30 
lor or other means to provide a random seed number. 
At step 103, the time-varying value TS and the secret 
session key KSS are concatenated and at 1 04 the result 
is encrypted with the server's public key PUBserv which 
has been retrieved from menrory 4 or 5. The encrypted 35 
message {KSSITS}PUBqerv 's sent to the sen/erat 1 07. 
The client's certificate (CERT-C) is retrieved from mem- 
ory. EPROM 3, at 1 05. encrypted with the secret session 
key KSS at 106 to form message {CERT-C)kSS which 
is sent to the server at 108, The sending operat tons 107 40 
and 108 may be combined into one operatton. 

Figure 3B illustrates the processing at a server 40 
of messages received from a client via IA:) port 63 for 
the purpose of ensuring the authenttoity of the client. In- 
itially, the sender decrypts at 201 the message {KSS{TS) 45 
PUBsERv using its private key PRIVserv recovered from 
memory 61 . At 202 the received time-varying value TS 
is compared with a reference value obtained from the 
server's facility for generating a time-varying value 42. 
Where the values do not compare an error signal is gen- so 
erated at 207 and the process is terminated. Where the 
time-varying values compare, the processing continues 
at 203 with recovery of the secret session key KSS and 
at 204 by decrypting of the message {CERT-C)KSS us- 
ing the secret sesston key. This provid'es the sender with ss 
the client's certificate (CERT-C)"whicFris then at 205 
subjected to a public key operation using the trusted cer- 
tification authority's public key PUBjca retrieved from 
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memoiy 61. At 206 a veriftoation of the certificate 
(CERT-C) is performed with the subsequent generation 
at 208 of an error signal where the certificate cannot be 
verified or the generating off an authentk: signal at 209 
where the certificate is found to be authentic. The veri- 
fication procedu re at 206 may include the use of the CRL 
stored in memory 61 . 

One embodiment of the invention is a non-interac- 
tive version where the protocol requires only the sending 
of messages over a communications channel by a client 
to the server with which it is seeking to execute a trans- 
action. In other interactive emtKxJiments (Figures 4A, 
4B and 4C), a message, designated 11 in the drawing 
figures, containing informatfon needed by the client to 
produce authenticating messages for the server, e.g.. 
the public key of the server and/or a time^aiying value 
provkied by the server, is sent by the server to the client. 
In a further interactive embodinrvent (Figure 5), the client 
has need of assurance of the sender's presence in the 
transactton and therefore requires a message signed by 
the server Figure 6 represents a modificatton of the em- 
bodiments of the invent kxi due to the message gener- 
ated by the client having the time-varying value com- 
bined with the certificate of the client. Figure 7 shows a 
version of the inventon where a session key is not used. 
Moreover, Figures 8 to 10 illustrate modifications to the 
embodiments of Figures 5 to 7 wherein only a part of 
the client's certificate is encrypted. Additionally, Figure 
12 illustrates a fundamental protocol whereby a user 
can confidentially deliver to a verifier informatkxi which 
is essent'al to verify a message signed by a credential 
issuing authority, but whch may be modified to include 
one or nrx>re features of other disclosed embodiments. 

In the non-interactive embodiment, there is no mes- 
sage 11 sent from sender 40 to a client in the authenti- 
cation protocol. The protocol is essentially as shown in 
Figures 3A and 3B with a client configuration as in Fig- 
ure 1 and a server configuration as in Figure 2. The client 
upon gaining access to a server 40 obtains the sewer's 
publk; key from a local storage, generates a random se- 
cret sesskxi key KSS (102), concatenates (103) it with 
an internally generated time-varying value, encrypts 
(104) the result with the server's publk: key and sends 
the result to sender 40 (107), The client concurrently or 
subsequently retrieves its certificate (CERT-C) from 
storage (105) encrypts (106) the certificate.with the se- 
cret session key and sends the result to server 40 (1 08). 
In the non-interactive ennbodlment. there is no signing 
by the server or even the generation and sending of a 
message by the server. The client's confidence in the 
sender is assured by the use of the sender's public key. 
since only the server can decrypt a message encrypted 
with its public key. The authenticity of the client is estab- 
lished to the satisfactk)n of the server by its receipt and 
verricatkxi of the time-varying value and the cli ent'sce r- 
tifrcate by processing the received messages in accord- 
ance with the procedure shown In Figure 3B. 

In the interactive embodiments of Figures 4A. 46 
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and 4C. message 1 1 consists of a certificate (CERT-S). 
a time-varying value, or a combination of a certificate 
(CERT-S) and a time-varying value. These information- 
al items are provided to a client so that the client may 
properly form authenticating message 12. Figure 5 
shows an interactive embodiment where the server pro- 
vides a signed message 11 . Since Figure 5 is the most 
comprehensive, It will be described first, and the embod- 
iments of Figures 4A, 4B and 4C described primarily 
with respect to differentiating features caused by the dif- 
ferences in the content of message 11 . 

In Figure 5. the parties to the electronic transaction 
are the client 20 and the sender 40. Messages 11. 12 
and 1 3 are generated and exchanged between the client 
20 and the server 40 over a communications channel 
15. Successful exchanges of the messages establish 
the trust of the client 20 in the server 40 and the authen- 
ticity of the client 20 to the server 40. Communications 
channel 15 may simply be electrical connections be- 
tween a card reader and the terminal equipment at a 
server or may be in the form of a telephone or other com- 
munications link established between a client and a re- 
mote server, or other conventional communications me- 
dium. 

Client 20 includes a certificate (CERT-C) 21 stored 
in EPROM 3, a key generator (KEY) 22, a facility for gen- 
erating a time-varying value (TS) 23 whidi may include 
the clock 8. when used, arKl the public key (PU&toa) 24 
of the trusted certification authority which may be stored 
in EPROiy/l 3 or PROM 4. Certificate 21 comprises a 
message provided and signed by the trusted certifica- 
tion authority with its private key in the standard manner. 
The message in this instance need not be the client's 
public key because this key is not involved in the proto- 
col. Any message is sufficient and may be certain well 
structured informatk^n about the client, e.g., account 
number and expiration date of the account The mes- 
sage fnay also Indicate the types of transacttons for 
which the client 20 is authorized and the period of time 
during which the certificate may be conskjered valkJ. 
The key generator 22 is comprised of any conventk>nal 
means of generating an encryptkwi key. It may comprise 
a subroutine in the processor and use a number sup- 
plied by a number generator 7. The facility 23 way conn- 
prise conventional clock 8 that provkJes a current date 
and time or may be one that operates on a received 
timestamp or time-varying value. Key 24, the public key 
of the trusted certification auttiority, is used to verify a 
certificate sent by the server and signed by the trusted 
certificatkxi authority. 

Key storage unit 25 represents an optional menoory 
or memory section for storage of keys of one or more 
frequently used servers. These are the public keys of 
servers and are made available to clients by the servers. 
Storing the public key of server 40 and other selected 
servers at the client avoids the need to process the cer- 
tificate from a server to recover the key, or provides a 
source for the key where the certificate does not contain 



the public key or an easily recoverable copy of the public 
key of the server. CRL storage unit 26, also an optional 
memory or memory section, stores a list of certificates 
that have been revoked. 
s Elements 30 through 35 illustrate the functional 
processes of the protocol pertormed by the client to es- 
tablish trust in the server. Public key operations are con- 
ventfonal well known processes in the art. Recovering 
the public key of the server from the server's certificate 

10 for the key and storing it in a memory, as illustrated in 
block 30, is a certificate processing within the skill of art. 

Functional element 32 represents a public key op- 
eration pertormed with the trusted certification authori- 
ty's public key 24 on the certificate portion of the mes- 

IS sage 1 1 received from the server 40. Functional element 
31 represents a public key operation performed on the 
timestamp or other time-varying value received from a 
server with the server's public key obtained from 
processing the certificate at read and store element 30 

20 or from key storage unit 25. At functional block 33 a 
standarcf verification procedure, as those skilled in the 
art apprecate, is used to verify the certificate. A certifi- 
cate revocation list supplied from memory 26 may op- 
tionally be used in verifying the certificate. 

25 Functional element 34 represents a comparison 
and verificatkxi of the timestamp or time-varying value 
received from the server 40 to verify that it Is proper. 
Where the smart card or client has a clock, a simple 
comparison (allowing for small time differences) of the 

30 time at clock 6 with the time of the received timestamp 
isutflces to verify a received timestamp. Where the smart 
card does not include a ckxk. the stored time of a last 
received vaiki timestamp can be compared with the time 
of the currently received timestamp to verify that the cur- 

35 rently received timestamp is later in time. Any time-var- 
ying value may be received and processed to verify that 
it is of recent origin or in a proper time sequence. 

Failure to verify the server's certificate or time-var- 
ying value (illustrated by the NO outputs of elements 33 

40 and 34) results in an error and termination of the trans- 
action. Symbol 35 is a representaVton that permits fur- 
ther processing, Le. the generation of the secret session 
key. when both the receh/ed certificate and time-varying 
have been verified (indicated by YES outputs of ele- 

4B ments 33 and 34). 

Elements 36. 37 and 38 illustrate the functkxial 
processes pertormed by the client 20 to generate mes- 
sages 1 2 and 1 3. Message 1 2 is generated by concate- 
_natlng the sesskxi key 22 and the time-varying value 

^0 from facility 23 at element 36 and performing a public 
key encryptkxi on the combination in public key opera- 
tion 37 with the public key of server 40 retrieved from 
read and store element 30 or key storage unit 25. Mes- 

sage 1 3 is generated by performing an encryption at el- 

.55 -errient 38 on the certricate 21 with the session key 22. 
The functional elements and blocks of client 20 de- 
fine operational steps perfonmed by a processor, e.g., 
processor 2 of Figure 1 . Similariy, the functional ele- 
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ments and blocks of server 40 illustrate operBtlonal 
steps performed by the server's processor 60. 

Server 40 of Figure 5 includes a certificate (CERT- 
S) 41 provided by the trusted certification authority, a 
facility for generating time-varying values (TS) 42. the 
private key of the server (PRIVserv) 43 and the public 
key of the trusted certificatton authority (PUBjca) 44. 
Certificate 41 is a certificate for the server's 40 public 
key. and contains a message which includes the serv- 
er's publk: key and that Wentifies the server as a valid 
and authorized holder of the public key. Facility 42 may 
be provided by a clock. The key 43 is the server's private 
key of the public key/private key pair used in standard 
public key cryptography Key 44 is the public key of the 
trusted certification authority. CRL 45 is an optional el- 
ement that stores certificate revocation lists for both 
server's and client's certificates. These lists are signed, 
dated messages received from the trusted certificatbn 
authority The server CRL is for fon/varding to a client 
during the herein described protocol or ancillary to the 
protocol. The client CRL vwould sen^e, for example, as 
a list of revoked smart cards. I.e., cards that have been 
lost, stolen, destroyed or that have expired. 

The server's certificate and private key, the public 
key of the certification authority and the CRL are stored 
in memories of the server. These memories are ac- 
cessed by a processor of the sender in accordance with 
an operating procedure for executing the authentrcatran 
protocol. 

Elements 1 7 and 18 illustrBtethe functional process 
for generating message 1 1 . The time-varying value from 
facility 42 is signed with the private key 43 of the sender 
40 in private key operation 17. The signed time-varying 
value is then concatenated with the certificate 41 in the 
concatenate operatton 18 to thereby fonm message 11. 

Blocks and elements 51 through 56 represent iunc- 
tional processes of the protocol performed by the server 
40. Functional element 51 performs a private key oper- 
ation with the private key 43 on the received message 
12, A comparison at 52 provides verification of the time- 
varying value received from the client 20. This may be 
done by comparing a timostamp received with the cur- 
rent timestannp of a clock from facility 42, or by storing 
a time-varying value sent to the client and comparing 
the stored time-varying value with the time-varying val- 
ue retumed by the client to see that they are in cone- 
spondenca. Gate symbol 53 represents the permissive 
continuation of the processing upon the verification of 
the receipt of a proper time-varying value. Furwtional 
element 54 perfonms a decryption of the message 1 3 
using a key 22 received from the client 20. Functional 
element 55 perfonms a public key operatbn on the cer- 
tificate with the public key 44 of the trusted certificatkxi 
authority. Block 56 provides for the verification of the 
certificate withoir without the CRL of clients in a manner 
well understood by those skilled in the art. 

Initially, the client 20 may have to gain the trust of 
the sender 40 before it will reveal its certificate 21. This 
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protects against revealing the certifteate to unauthorized 
third parties who could then use the certificate to imper- 
sonate client 20. Client 20 gains the trust of the server 
40 through a public key protocol. 

Considering the Figure 5 illustration, so that client 
20 nnay gain Its trust, upon a request for access the serv- 
er 40 reveals its certificate 41 by combining the certifi- 
cate 41 with the signed time-varying value from facility 
42 to form message 11 CERT-S{TS}PR1Vserv Client 
20 receives the message 11 sent over the communica- 
tions channel 1 5, verifies the signature on the certificate 
with the trusted certification authority's publfc key 24 in 
public key operation 32 and verificatKm process 33, and 
processes the certifteate in operatwn 30 to read and 
store the public key of the server Client 20 then uses 
the public key of the sender in public key operation 31 to 
obtain the time-varying value. As indicated above, the 
public key of server 40 alternatively may be retrieved 
from public key storage unit 25 where used. Checking 
of the time-varying value to see that it is valid is done in 
comparison unit 34. A failure to verify the server's cer- 
tificate or valWate the received time-varying value ter- 
minates the transactbn. Signature verification, particu- 
larly for RSA, is computationally inexpensive, so the 
conrputatranal burden on the client 20 is minimal. As an 
additional step in certificate verification, the client 20 
may check the values of one or more fields of the cer- 
tificate 41 to determine whether the server 40 is author- 
ized for transactions with the client 20. It is presumed 
that the trusted certification authority of interest issues 
authorized certificates only to trusted servers, so the 
pair of signature verifications is sufficient for the client 
20 to gain trust in the server 40. 

Once client 20 verifies the time-varying value from 
42 and the certificate 41 of sender 40. trust of the server 
40 is established. Thereafter, client 20 generates a ran- 
dom secret sesskxi key (KSS) at 22. combines this key 
with its time-varying value (TS) generated by a clock at 
23. or where no ckx:k is present replicates the time-var- 
ying value received from the server, tofomn a message 
and encrypts the message with the public key (PUB. 
sERv) of server 40 obtained from storage at element 30 
or 25 to form the encrypted message 1 2. Again, for RSA, 
encrypting with the sender's public key is computation- 
ally inexpensive so this is not a burden on the client. 

The encrypted message 12. {KSSITSIPUBserv* 's 
sent to the server 40 where it is received and processed 
for recovery of the secret session key KSS by decrypting 
the message 12 with private key 43 in private key oper- 
ation 51 . A checking of the time-varying value TS dem- 
onstrates to the server 40 that a client is active in the 
transaction, not an impersonator replaying a recorded 
message. 

Client 20 then encrypts its certificate 21 using the 
secret session key to pr oduce encrypted message 1 3. 
{CERT-C)KSS, and sends it to server 40. Messages 12 
and 13 may be connbined as one message {KSSITS} 
PUBsERv{CERT-C} KSS. Sender 40 receives the en- 
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crypted message 1 3 and decrypts rt in decryption oper- 
ation 54 to gain the client's 20 certificate 21 . Certificate 
21 is processed in public key operation 55 with the trust- 
ed certification authority's public key stored at 44. After 
veriflcalion at 56, with or without the optional CRL in unit 
45, the authenticity of client 20 is accepted by sender 40 
and the transaction can be undertaken. 

When clocks are used for both timestamp facilities, 
the client and the server need to account for variations 
in their clocks when checking that the timestamp re- 
ceived Is current One procedure is to determine the dif- 
ference between the two clock timestampe. for example, 
the client determines the difference between the re- 
ceived timestamp £ind its own clock generated times- 
tamp. and compares that difference to a pre-set refer- 
ence value to see that it is less than the reference value. 
Other techniques known to those skilled In the art may 
be used to account for the clock variatons. See, tor ex- 
ample, Weiss. U.S. Patent 4.885.778, entitled "Method 
and Apparatus for Synchronizing Generatkxi of Sepa- 
rate Free Running, Time Dependent Equipment,* which 
describes a technique for synchronizing client and serv- 
er clocks in an authorization protocol. 

In place of a timestamp a challenge may be used. 
A challenge may comprise any-time varying message 
that can be processed and verified. 

The client may also store a CRL of servers. Either 
as a part of the authentication protocol or subsequent 
thereto, the server and the client n^ay exchange lists of 
revoked certificates. 

In the embodiment illustrated in Figure 4A. mes- 
sage 11 consists of the public key certificate 41 of server 
40. Here, client 20 does not have or need to have prior 
possession d the server's public key. Possession of the 
server's public key is acquired by the client receiving 
and reading the public key certificate 41. The signature 
on the certificate is verified with the Trusted Certification 
Authorrt/s publk: key 24 and the certificate is verified by 
con ventkxial verification procedures as discussed in the 
descriptkxi of Figure 5. This publk: key of the server is 
then used in public key operatfon 37. The time-varying 
value is generated kxally at facility 23. As seen from 
Figure 4A, client 20 comprises only the elements, e.g., 
24, 32, 33 Eind 26 to verify the certificate and Its signa- 
ture and a functional element 30 to read the received 
certificate 41 and store the public key PUBserv- 
server's processing to form message 11 involves only 
the sending of its certificate 41. The remainder of the 
components, functkxial elements and operations of fig- 
ure 4A correspond with those in Figure 5. 

In the embodiment of Figure 4B. the message 11 
consists of certificate 41 and a time-varying value TS, 
The time-varying value TS is needed where a client 20 
does not have a facility for generating its own time=var- 
ying value. Thus, as shown, server 40 forms message 
1 1 by concatenating at element 1 6 the certificate 41 with 
the time-varying value from facility 42. In Figure 4B, cli- 
ent 20 verifies via 24, 32 and 33 the signature on the 



certificate, opttonally via 26 the revocation status of the 
certificate and at functional element 39. reads and 
stores the server's public key and the time-varying value 
sent by the sen/er. The time-varying value is processed 

s and replicated or modified for use in forming message 
12. This embodiment is advantageous since its Imple- 
mentation requires few structural components and com- 
putational operatk>ns. The client simply obtains the val- 
ue TS and public key of the server needed for generating 

10 message 1 2 from the server. The server then processes 
the messages received as in the prevbusly described 
embodiments. When a timestamp is not used by the 
server as the time-varying value, neither the server or 
the client needs a clock. Public key storage element 25 

IS is optional. 

In Figure 4C, message 1 1 consists of a time-varying 
value TS. As previously described, client 20 may have 
no clock or timestamp facility. It therefore has to receive 
a time-varying value at facility 23 or the like. Again, the 

so received time-varying value may simply be replicated, 
or modified in a predetermined manner, and returned to 
server 40 in message 1 2. This assures the server that 
a current transaction is taking place. Again, neither party 
needs a clock, l-lowever, the client has to have a stored 

2S copy of the public key of server 40, i.e., an element 25 
of memory 4 with a stored copy of the public keys of 
varkjus servers with which it will interact Server 40 only 
requires the message generating elennents necessary 
to send a time-varying value. The remaining elements 

30 depicted in Figure 4C are like those in Figure 5 and op- 
erate in a similar manner. 

The content of the messages generated and sent 
by a client to a server may be as shown in Figure 6. Here 
the time-varying value is concatenated with the certifi- 

35 cate of the client instead of with the secret session key. 
As shown, client 20 in public key operation 37 encrypts 
the secret session key with the server's publfc key. the 
sen/er's public key being produced as in any of the pre- 
viously described embodiments, concatenates at 36 the 

40 time-varying value, obtained as In any of the previously 
descrtoed embodiments, with the client's certificate 
(CERT-C). and encrypts at 38 the result using the secret 
sessk>n key. The processing in the server is nfKXjtTied to 
accommodate the change in the messages 12 and 13, 

4S causing the time-varying value verification to be subse- 
quent to the decrypting at 54. The server decrypts mes- 
sage 1 2 using its private key to recover the session key 
and decrypts the time-varying valuelceriificate with the 
secret session key The certificate is subjected to a pub- 

so lie key operation and verifying procedure as in elements 
such as 55 and 56 as shown in the Figure 5 eml>odi- 
ment. The variation shown in Figure 6 may be practiced 
with any of the emlxxiiments hereinbefore described. 
In some instances a session key in not used, as for 

ss exsinnple where the 8Ut>sequent communteations of the 
overall transactk>n session are not encrypted. The cli- 
ent's certificate is simply concatenated with a time-var- 
ying value and the result is encrypted with the server's 
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public key to form the message 1 2 which is sent directly 
to the server. Figure 7 shows, in part, a protocol that 
does not use a session key The client 20 concatenates 
at 36 a time-varyin g value produced as in any of the pre- 
viously described embodiments, and encrypts at 37 the 
result with the server's public key obtained as in any of 
the previously described embodiments. Server 40 de- 
crypts the message at 51 with its private key, verifies at 
52 the time-varying value, and processes the client's 
certificate as hereinbefore described to authenticate ft. 
A smart card using this protocol may only comprise a 
processor, a memory storing the certificate for the card 
and the public key of servers and a facility for providing 
a time-varyhg value. The smart card may then engage 
in a non-lnteractJve protocol with a server for the pur- 
pose of establishing its authenticity to a sender. In an 
interactive protocol, the sen/er In a communicatkxi to 
the client provkies a time-varying value and its public 
key certificate as in Figure 4B. and the smart card proc- 
essor processes the receipt of same to produce a time- 
varying value and the public key of the sender. The other 
interactive embodiments of Figures 4A and 4C and Fig- 
ure 5 may also be modified to have no session key. 

It is also possible to nxxiify the aforementioned em- 
bodiments to encrypt only part of the certificate, which 
may lead to greater efficiency in the protocol. For in- 
stance, the client can encrypt only the signature on the 
certificate, transmitting the rest of the certifk:ate unen- 
crypted. Since a certifteate is not valid without a signa- 
ture, an opponent who obtains only the non-signature 
part of the certificate will not be able to impersonate the 
client. 

As a genersUizatbn. the client can erwrypt any data 
essential to the verification of the certificate. The signa- 
ture is one example; anc^er example is a part of the 
signature, large enough so that the opponent cannot 
guess it. A third exannple is a secret certificate serial 
number assigned by the certification authority. In gen- 
eral, the most efficient approach, in terms of communi- 
cation requirements, is to encrypt somethhg that is al- 
ready required by the server, rather than something 
new. Since the signature is already required, it is a nat- 
ural choice, though other parts of the certificate may be 
appropriate as well. 

In some cases, it may be more efficient in terms of 
communication band wkith to encrypt more than just the 
data required to verify the certificate. For instance, if the 
encryptran is perfomnod with the public key of the server, 
then the client can encrypt as much addrttonal data as 
can be encrypted with a single public-key encryption op- 
eratkxi. The approach of erK:rypting the entire certificate 
is an extreme example. As another variaton, it is pos- 
sible to encrypt part of the certificate with a public-key 
encryption, and part with a secret-key encryptkxi. 

Figure B itlustrates in part a variation of the embod- 
iment of Figure ^TWherein only a portion of the certificate 
21 is encrypted and transmitted to the sender 40 with the 
remainder of the certificate (REST-C) being transmitted 
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in unencrypted form. Thus, the certifrcate 21 can be split 
at 81 so that any data in the certificate which is essential 
to the verification of the certificate is split and subse- 
quentfy encrypted by secret session key (KSS) at 38. 
The remainder of the certificate (REST-C) is transmitted 
unencrypted to the server 40. 

Upon receipt of the transmitted encrypted and non- 
encrypted portions of the certificate the server 40 de- 
crypts the former at 64 and joins the latterat element 62 
so as to obtain the clients certificate 21 . Thereafter as 
illustrated in Figure 5, the certificate is processed in pub- 
lic key operation 55 with subsequent verification at 56. 
As previously noted, the encrypted portion (X-C) of the 
client's certificate nnay bo any portran which is sensitive 
or essential to the verificatton of the certificate such as 
the signature or a portkxi of the signature. 

Figure 9 is an illustratton of a variation of the em- 
bodiment of Figure 6 wherein only a portion (X-C) of the 
client's certificate 21 is encrypted with the remainder 
(REST-C) being transmitted in unencrypted form. In this 
regard the certificate 21 is again split at 81 to obtain an 
essential portion (X-C) of the certificate. Thereafter, as 
may be seen from Figures 9 and 6. the essential portion 
of the certificate is concatenated at 36, encrypted at 38 
and transmitted to the server 40. Moreover, the unen- 
crypted portion (REST-C) of the certificate 21 is trans- 
mitted to the server 40 for joining at 82 with the decrypt- 
ed portion (X-C) for subsequent verification of the cli- 
ent's certificate 21. 

Figure 10 illustrates a variation of Figure 7 wherein 
only an essential portkxi of the client's certificate 21 is 
encrypted with the remainder of the certificate being 
transmitted unencrypted. More specifically, the certifi- 
cate 21 is split at 81 to form an essential portion (X-C) 
which is concatenated and encrypted at 36 and 37. re- 
spectively, for transmission to the server 40. Meanwhile, 
the rest of the certificate (REST-C) is transmitted to the 
server in unencrypted form lor joining at 82 with the es- 
sential portion of the certificate as decrypted at 51 and 
52 to thus provide the sender with the client's certifkjate. 

Another approach applies when the certificate con- 
tains a field that is computed as the one-way functton, 
such as acryptographic hash function, of a secret value. 
In this case, the secret value is encrypted and transmit- 
ted to the server, and the server computes and com- 
pares the one way function of the received secret value 
to the field in the certificate, after verifying the cert ificate. 
This has the advantage that the secret value can be con- 
cealed from the certification authority during the process 
of obtaining a certificate, so that the certification author- 
ity cannot later impersonate the client. The approach of 
encrypting a secret data value whose one-way function 
value is contained in the certificate has this property. A 
related approach is described in the Secure Electnxiic 
Transaction Specification (Mas terCard and Visa, June 
24, 1996). In SET, the name fieW in a certificate is 
formed as a one-way hash of the account number and 
other information, and during a purchase protocol, the 
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account number and the other information are encrypt- 
ed and transmitted to a server, which compares their 
hash to the name field of the certificate. However, au- 
thentication in SET is also based on digital signatures, 
as in other conventional approaches. The account 5 
number itseJf is concealed tor the protection of the ac- 
count owner, not prinnarily for authentication, and it is 
not concealed from the certification authority. 

Related to this, there could be a hash-tree of secret 
values whose root is included in the certificate, where a 
path through the tree is encrypted and transmitted to the 
server The hash-tree variation provides greater protec- 
tion against misuse by the server, since different paths 
could be associated with different servers. Here it is vn- 
portant to note that the path is encrypted. However, in is 
a different approach based on a hash tree, the root is 
included in the certificate and a digital signature, which 
need not be encrypted, is formed with the tree. See. for 
example. Merkle. U.S. Patent 4.309,569. entitled 'Meth- 
od of Providing Digital Signatures. ' In this regard, the 20 
storage requirement for the latter approach is quite large 
and may be Impractical in a smart card or similar proc- 
essor. 

Regarding hash trees, as may be seen in Figure 11 , 
a hash tree consists of a root and one or nnore children. 2S 
where if there is more than one child, each child must 
be a hash tree, and if there is only one child, the child 
is a leaf. A leaf has no children. A hash tree thus consists 
of many leaves, connected to the root through interme- 
diate nodes. Each leaf has a predetermined value. The 30 
value of a hash tree Is the hash of the values of its chil- 
dren and the value of a hash tree is thus computed re- 
cursively. 

A path through a hash tree consists of a leaf and 
the values of the siblings of its successive parents. A 35 
path is verified by recalculating the value of the root 
based on the values in the path. This can be done re- 
cursively, since the value of each child of the root is ei- 
ther in the path, or can be recalculated from the rest of 
the path. As may be seen In Figure n . the path from X3: 40 
X3, h()Q), h(h(X|), htXg)) can be verified by recalculating 
the root given the values of siblings In the path. 

Only one leaf is contained in a path, and provided 
that the hash function is one-way, the values of leaves 
not in a given path cannot be determined from the path. 45 
Thus, it is possible to reveal paths for each leaf in the 
tree such that.a different path is used tor each verifier, 
so as to prevent misuse. Only the root needs to be trust- 
ed initially by a verifier. It should be noted that the pre- 
viously mentioned approach of storing the hash of a se- so 
cret value in the certificate Is really just a special case 
of a hash tree, where there is only one leaf. 

In the above described protocols, the server 40 can 
easily recover the certificate sent by client 20 but no third 
party can because only client 20 and server 40 know the ss 
secret sessbn key and/or only the server knows its pri- 
vate key. The server 40 is convinced that the client 20 
is authentic and active in the transaction. Client 20 Is 
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assured that Its certificate is seen only by server 40. 
While server 40 has enough information after a trans- 
action to impersonate client 20, server 40 is of such in- 
tegrity as to be trusted not to reveal the client's certificate 
to any third party or to impersonate client 20. 

Trust of server 40 is a realistic consideration since 
servers are currently trusted to not reveal passwords or 
other data betonging to a client. In financial applications, 
the server (card reader) is trusted not to reveal account 
numbers or a personal kJentification number (PIN). 
Thus, it is reasonable to assume that the server or card 
reader will not reveal certificates. 

In the case of RSA. the encryptkxi and signature 
operations can folbw the techniques described in PKCS 
#1: RSA ENCRYPTION STANDARD (RSA Laborato- 
ries. November 1993), in International Standard 9796: 
Information Technology, Security Techniques: Digital 
Signature Scheme Giving Message Recovery (ISO/ 
lEC. 1991), in M. Beilare and R Rogaway, 'Optimal 
Asymmetric Encryption" in Advances in Cryptology - Eu- 
focrypt •94, pp 92-111 (Springer-Verlag (New York 
1995)) or in similar standards, as are well known to 
those familiar with RSA. 

The client and server certificates may be signed by 
the same trusted certification authority or different trust- 
ed certification authorities. The client and server, in ei- 
ther case, needs to have in its possession, the public 
key of the trusted certification authority that signed the 
received certificate in order to verify it. 

In the above noted embodiments where the server's 
public key Is provkJed to the client, the same server pub- 
lic key was used for encryption and verification. Howev- 
er, the public key of the server 40 for encryption may be 
different than the public key for verifying signatures. In 
Figure 5. for example, elements 31 and 37 could employ 
different pubic keys by storing two different public keys 
associated with the same server, one of which would be 
for verifying the server signatures at 31 and the other 
for encrypting data at 37 to be sent to the server Alter- 
natively, the certificate of the server could contain two 
separate keys along with kientification as to their pur- 
poses. Moreover, in either alternative, element 43 of Fig- 
ure 5, for example. wouW provide appropriately different 
private keys to elements 17 and 61. 

As an additional modification to the disclosed ex- 
emplary embodiments, the client's certificate (CERT-C) 
may be generated once by the certification authority and 
stored in the client's memory 21 or it may be a certificate 
generated by a certification authority whenever the cli- 
ent is authenticated to the certification authority, e.g. as 
part of a dally log-in procedure. Moreover, the authenti- 
cation operation couW be carried out by techniques de- 
scribed herein or by other authentication techniques. 
The new certificate could also contain the time at which 
authentication occurred and could expire later at some 
set time. Thus, the exposure time of the certificate would 
be limited if It Is obtained by an opponent. The new cer- 
tificate could also specify the types of operations for 
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Which the client is currently authenticated Under such 
circumstances, the client would present the new certifi- 
cate to the sender to authenticate itself to the server, and 
the server would check that the certificate has not ex- 
pired and that the client is authorized for a particular type 5 
of operation. 

In financial applicatbns, a certificate can be easily 
authenticated since it carries the digital signature of a 
certificatbn authority. An account number cannot be 
easily authenticated because checking is done through 10 
accessing an on-line database. Therefore, in a financial 
applicatk)n the certificate has clear benefits over an ac- 
count number or an account number in combination with 
a PIN verificatran procedure. 

In additkxi, If the account number contains check J5 
digits, they can usually be constructed by any third party 
with a public algorithm. TTius a third party can easily 
forge account nunnbers. For this reason, a database 
check is essential. Moreover, if the check digits are com- 
puted based on a secret key stored in the server, the 20 
same secret key must be stored in all servers. There- 
tore, an opponent who compromises one server can 
forge account numbers. This is another reason for the 
practice of having a central database perform the check. 
With certif bates, the server stores only the trusted cer- 25 
tification authorit/s public key, not the private key. Thus 
an opponent that compromises a server may obtain ac- 
cess to certificates known to that server, but does not 
gain the ability to fomn new ones. 

As previously noted, the system as illustrated in Fig- 30 
ure 1 2 Is more fundamental and has a more general pro- 
tocol whereby a user is enabled to confidentially deliver 
a credential authorizing the user to perform an opera- 
tion. In order to reflect the more fundamental system and 
protocol the terms "user", "credential" and "verifier* are 35 
used rather than "client", "certificate" and "server", re- 
spectively, so as to indicate the more general nature of 
the Figure 12 exemplary enrU)odiment. In Figure 12 the 
credential includes information essent'al to verify the 
credential which is transmitted to a verifier by way of an 40 
errciypted communications channel. In the illustrated 
system the user 60 may be an Individual, a computer or 
some other entity. Moreover, the credential can be 
stored on a smart card or other devtee held by the user 
or may be heW on the user's computer. Furthermore. ^5 
the encrypted communicalk>n6 channel 65 can be be- 
tween the user's smart card and the verifier or the user's 
computer and the verifier. Additionally, the verifier can 
t>e a client, a sender or some other entity on a computer 
network having a secure channel connected to the user 50 
whereby at least data essential for verifying the user's 
credential is transmitted to the verifier 

Although the credential held by the user would in- 
clude a digital signature by a credential issuing authority, 
It is ont y_riec e83afy for the system illustrated in Figure 55 
12 to transmit some portbn of the credential which 
would be necessary for verification of the credential to 
be transmitted to the verifier via the encrypted channel. 
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That is to say, although the entire credential could be 
provided to the verifier via the encrypted channel, en- 
cryptfon coukl be limited to only portions essential for 
verification such as the digital signature on the creden- 
tial, encryption of a secret value whose one way function 
value is stored in the credential or encryption of a path 
through a hash tree whose root is stored in the creden- 
tial. Thus, element 62 would select all of the data of cre- 
dential 61 or at least an essential portion thereof for 
transmission via the encrypted connmunication channel 
66 for verification at 71 as illustrated in Figure 12. Other 
non-selected data would be transmitted through a non- 
encrypted channel and input to the verification step in a 
manner similar to that which is illustrated in Figures 6 
through 10, for example. 

Stated differently, with regard to the embodiment of 
Figure 12. although It Is possible for all data of the cre- 
dential to be transmitted through an encrypted channel, 
the primary focus of Figure 1 2 is that only data essential 
for verification need be transmitted through the encrypt- 
ed channel. Additbnally, it is important to note that the 
operation as Illustrated In Figure 12 does not depend on 
operations with keys belonging to the user such as a 
digital signature by the user. Such keys, however, can 
be included in the credential, but verification operations 
do not depend thereon. 

The credential can be verified by verifying the digital 
signature with the public key of the credential issuing 
authority and/or by pertonming other operatk)ns previ- 
ously disclosed such as comparing the computed one 
way function of a transmitted secret value to the com- 
puted one way function of the secret value included in 
the credential or by checking the path through a hash 
tree. 

With regard to the encrypted communications chan- 
nel, the channel may comprise encryptbn with a secret 
key which is shared by both the user and the verifier, by 
the user's computer and the verifier or by encryption with 
the verifier's public key in a manner similar to that illus- 
trated in the embodinnent of Figure 7. Where a shared 
secret key is used, the secret key nrtay be established 
by any of a number of technk^ues Including the use of a 
third party key server, the user or the user's computer 
generating a random secret key and encrypting it with 
the verifier's public key and sending it to the verifier as 
in previously disclosed embodiments. Moreover, a time 
stamp or other non-repeating values may be Included 
in the process of establishing the key as in prevbus em- 
bodiments or by encrypting the data necessary to verify 
the credential or both. Addrtbnally. in the event that en- 
cryption on channel 66 uses the verifier's public key. as 
in prevbusly disclosed embodiments, a certificate for 
the verifier's public key may be verified first by the user 
or its computer. _ 

As in the pre viously disclosed embodiments, the 
verifier of Figure 12 is trusted not to reveal or misuse 
the user's credential. Moreover, since the data neces- 
sary to verify the credential is encrypted, the user is pro- 
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tected f rom opponents who cannot compromise the ver- 
ifier's security. Moreover, since the credential includes 
a digital signature, the system is protected from oppo- 
nents who can compromise the verifier's security since 
they can only reuse existing credentials and cannot gen- 
erate new ones. In this regard, as noted with the previ- 
ously disclosed embodiments, the user's credential can 
be obtained as a one-time value resulting from a suc- 
cessful log-in operation or can be obtained at some oth- 
er interval. That is to say, the credential may authorize 
the user to perform certain operations and can also have 
further restrictions, such as limited time periods or limi- 
tations as to a list of authorized verifiers or servers. 

In any event, the system as illustrated in Figure 12, 
for example, provides the fundamental features of al- 
lowing a user to confidentially deliver to a verifier infor- 
nation which Is essential for verifying a credential as- 
signed by a certification authority which authorizes the 
user to conduct some transaction wherein the credential 
may or nnay not involve the use of a one way function 
but always contains the digital signature of the creden- 
tial issuer. 

Moreover, although the system illustrated in Figure 
12 merely illustrates the functional elements and blocks 
of a more fundamental system rivoMng confidential de- 
livery to a verifier of infomriation essential for verifying 
whether a user is authorized to perform an c^eration. 
various features of the previously disclosed emtxxii- 
ments may also be included in the Figure 12 embodi- 
ment. For example, as previously noted. etK^ryption on 
the encrypted connmunication channel 66 may be ob- 
tained with a shared secret key pre-installed with the 
user and verifier or established by encryptkxi with the 
verifier's public key. Alternatively, other well known tech- 
nk^ues for establishing a secret key by agreement can 
be used such as through the use of a Diffie-Hellman al- 
gorithm. Addftkxialty, encryption as in the emtKXjiments 
of Figures 4A through 7 may be obtained through the 
use of the verifier's public key or the use of a non-re- 
peating value such as a time stamp. Moreover, as afore- 
mentioned, the entire credential may be encrypted or 
only essential data of the credential may be encrypted 
with the rennainder of the credential being transmitted 
unencrypted in the manners illustrated in Figures 8 
through 10. for„ example. 

While the invention has been described in connec- 
tion with what is presently considered to be the most 
practical and preferred embodiment, it is to be under- 
stood that the Invention is not to be limited to the dis- 
closed emtxxliment, but on the contrary, is intended to 
cover vark>us modificatkxis and equivalent arrange- 
ments included within the spirit and scope of the ap- 
pended claims. 



Claims 

1 . A method for establishing the authenticity of a client 



in a client-server electronic transaction where a 
server having a public key/private key pair and a 
certification authority's public key and a client hav- 
ing a certificate signed by the certification authority 
s are coupled by a communications channel compris- 
ing. 

the clienU 

a) generating a secret session key, 
10 b) producing a time-varying value. 

c) concatenating one of the secret session key 
or the certificate with the time-varying value, 

d) encrypting the secret session key or the se- 
cret session key concater^ted with eaid time- 

IS varying value with the server's public key to pro- 

duce a first message, 

e) encrypting at least a part of the certificate or 
the certificate concatenated with the time-var- 
ying value with said secret session key to pro- 

20 duce a second message, arKl 

f) sending the first and second messages to the 
server, where a decrypting operation by the 
server on the first message with the private key 
of the public key/private key pair provides the 

25 server with-the secret session key. a decrypting 

operation on the second message with the se- 
cret session key provkdes the server with at 
least a part of the client's certificate, the de- 
crypting operation with one of the keye provides 

30 the time-varying value, and a verifying opera- 

tion on the time-varying value and a public key 
operatkxi with the certification authority's public 
key and verifying operation on the client's cer- 
tificate establish the authenticity of the client. 

3S 

2. A method as in claim 1 wherein the client's certifi- 
cate connprises structural informatkxi about the cli- 
ent but no publte key 

40 3. A nrtethod as in daim 2 further including said sen/er 
sending a time-varying value to the client, sasd client 
using the received time^rying value for the time 
varying-value that is concatenated with the secret 
session key or the certificate. 

45 

4. A method as in claim 1 further including the server 
sending a time-varying value to the client, said client 
using the received time-varying value for the time- 
varying value that is concatenated with the secret 

so session key or the certificate. 

5. A method as in claim 1 wherein establishing the au- 
thenticity of the client is non-interactive. 

S5 6. A method as in claim 2 wherein establishing ttiirau- 
thenticity of the client is non-interEictive. 

7. A method as in claim 1 wherein the certificate in- 
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eludes a first data portion which is essential for ver- 
ification of the certificate and a second data portion, 
&aid HDsthod prior to executing step e) splitting said 
first data portion from said second data portion, 
sending said second data portion to the sender with- 
out encryption, enciypting and decrypting the sec- 
ond message in steps e) and f), respectiveiy, only 
said first data portion, of the certificate, joining said 
first and second data portions at the sewer and 
thereafter performing the verifying operation of step 
0. 

8. A method as in claim 1 , wherein the certificate in- 
cludes data essential for verification of the certifi- 
cate as well as non-essential data and only the es- 
sential data is encrypted and decrypted respective- 
ly in steps e) and f ). 

9. A method as in claim 4, wherein the certificate in- 
cludes data essential for verification of the certifi- 
cate as well as non-essential data and only the es- 
sential data is encrypted and decrypted respective- 
ly in steps a) and f ). 

1 0. A method for establishing the authenticity of a client 
in a client-server electronic transaction where a 
server and a client are coupled by a communica- 
tions channel, comprising, 

establishing a client's trust in the sender over 
the communications channel, 
the client having stored in a menrK>ry a certifi- 
cate and the server's public key, and 

(a) generating in a processor, upon having 
established the trust in the server, a secret 
session key, encrypting the secret sesskxi 
key with the server's public key and send- 
ing the encrypted secret session key as a 
message to the server over the communl- 
cattons channel, and 

(b) encrypting at least a part of sakJ certif- 
tcaXe with said secret sesskxi key and 
sending the results of the encryptfon to the 
server over the conrvnunications channel, 

whereby decryption with the server's private 
key associated with the server's public key by 
the sender yields the secret session key and de- 
cryption of the results by the server with the se- 
cret session key produces at least a part of the 
client's certificate which is proof of the client's 
authentk^ity. 

11 - A method as In claim 10 where sakf certificate for 
the client includes structured information about the 
client but no public key. 



12. A method as In claim 11 wherein said server has a 
public key certificate for its public key and steps in 
the method include sending said public key certifi- 
cate to the client, said client processing the public 

5 key certificate to verify it and to recover and store 
the server's publk: key and using the recovered pub- 
lic key or a diflerent public key of the server in the 
step of encrypting the secret session key or the se- 
cret session key concatenated with a time-varying 

TO value. 

1 3. Amethodas in claim 1 2 further including sakJ server 
sending a time-varying value to the client, said client 
using the received time-varying value for the time- 

T5 varying value that is concatenated with the secret 
sesston key. 

14. A method as in claim 10 wherein said server has a 
public key certificate for its public key and steps in 

20 the method include sending the public key certifi- 
cate to the client, said client processing the public 
key certificate to verify it and to recover the senders 
public key and using the recovered public key or a 
different public key of the server in encrypting the 

25 secret sesston key or the secret session key con- 
catenated with a time-varying value. 

1 5. A method as in claim 1 4 further including the server 
sending a time-varying value to the client, said client 

30 using the received time-varying value for the time 
varying value that is concatenated with the secret 
session key. 

16. A nriethod as in claim 14, wherein the client's certif- 
^ icate includes data essential for verifrcation of the 

client's certificate as well as non-essential data and 
only the essential data is encrypted and decrypted. 

17. A method as in claim 10 wherein the step of estab- 
^0 lishing a clienrs trust fri the server Includes the client 

perfomnihg a publfc key pperatksn with a stored cer- 
tification authority's publte key tor the verifying of a 
certitkaite received from the server, processing the 
certificate received from the server to recover the 
45 publK key of the server, storing the public key of the 
server in saidrmemory and performing a public key 
operation with the server's public key for recovering 
an encrypted time-varying value received from the 
server. 

so 

1 8. A method as In claim 1 7 inci uding generating a lime- 
varying value and concatenating that time-varying 
value with the secret session key prior to the step 
^ encrypting with the server's public key or with the 

55 cert ificate p rfor to the step of encrypting with the se- 
cret session key. 

19. A method as in claim 18 wherein said server has 
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stored in memory its private key corresponding to 
said server's public key and the trusted certification 
authority's public key, and has a facility for generat- 
ing a time-varying value, 

said sen/er receiving said message and in a 
processor, decrypting said message with said pri- 
vate key to recover said secret session key. using 
said secret session key in a decrypting operation to 
recover the at least a part of the client's certificate 
sent by the client, one of the decrypting operations 
providing the client's time-varying vedue, checking 
the client's time-varying value by comparing it with 
a time-varying value from the facility and verifying 
the client's certificate in a public key operation using 
the trusted certification authority's public key. 

20. A method as in ctaim 1 9 wherein said server further 
includes stored in memory a certificate revocatk>n 
list and the step of verifying the client's certificate 
includes checking the certificate revocation list 

21. A method as in claim 20 wherein the client has 
stored in memory a certificate revocation listEuid in- 
cludes exchanging certificate revocation lists be- 
tween the server and the client. 

22. A method as in daim 16 including combining steps 
(a) and (b) to provkie a message, and sending the 
message over the communlcatkxis channel in one 
sending operatkn. 

23. A method as in cEaim 1 B including using a ckxk for 
generating the time-varying value in the form of a 
timestamp. 

24. A method as in claim 18 including generating the 
time-varying value by using the time-varying value 
received from the server. 

25. A method as in claim 10 wherein the generating of 
a secret sessk»i key includes the step of using a 
random number generated from a random number 
generator. 

26. A method as in claim 10 wherein the certificate in- 
cludes a first data portion which is essential for ver- 
ification of the certificate and a second data portion, 
said method prior to executing step a) splitting said 
first data portion from said second data portion, 
sending said second data portion to the server with- 
out encryption, encrypting in step a) and decrypting 
at the server only said first data portion, and joining 
said first and second data portions at the server af- 
ter decrypting said results. ^Z. 



27. A method as in claim 10 wherein the certificate in- 
cludes data essential for verificatk^ of the certifi- 
cate as well as non-essential data and only the es- 



sential data is encrypted and decrypted respective- 
ly by the client and server. 

28. A smart card comprising a processor, a read only 
s memory and an input/output port. 

said processor including 

means for producing a trusted server's 
10 public key, and 

means for executing a protocol stored in 
said menDory for establishing the authen- 
ticity of the smart card to a trusted sen/er 
and for generating a secret session key, 

16 

said read only memory having stored therein a 
certificate for the smart card, 
said protocol including encrypting the secret 
session key with the trusted server's public key 

20 and sending the ericrypted secret sessk>n key 

to the trusted server over the input/output port, 
said protocol further including encrypting at 
least a pari of said certificate for the smari card 
with said secret session key and sending the 

25 encrypted certificate to the trusted server over 

the input/output port. 

29. A smart card as in claim 28 wherein said read only 
memory has stored therein a plurality of publrc keys 

30 belonging to respectively, drfferent servers which 
may be used as a source from which the tmsted 
sewers' public key is produced. 

30. A smart card as in claim 28 further comprising a fa- 
35 cility for providing a time-varying value and means 

for concatenating the time-varying value with the 
secret sesskxi key or the certrfk^te. 

31. A smart card as in claim 30 wherein saki facility for 
40 providing a time-varying value comprises a clock. 

32. A smart card as in claim 30 wherein said facility for 
providing a time -varying value comprises means for 
storing a received time-varying value from a server 

45 and for supplying it or a nxxiification thereof as the 
time-varying value of the smart card. 

33. A smart card as in ctaim 30 wherein said processor 
further comprises means for establishing trust in a 

so server, said means including using a public key op- 
eration with a certificatkxi authority's public key for 
establish ing the Wentity of a sen/er and a timestamp 
of the facility for providing a time^arying value for 
establishing that a message received from"a"server 

^ comprising a timestamp is current. 

34. A smart card as in claim 28 wherein said certificate 
for the smart card includes structured information 
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about the smart card but no public key. 

35. A smart card as in claim 28 wherein said means for 
producing a trusted server's public key includes 
processing a public key certificate received from a s 
server. 



36. A smart card as in claim 34 further comprising a 
timestamp facility providing timestamps for verify- 
ing received timestamps and supplying a timestamp 
to messages generated by the smart card. 



37. A smart card as in claim 28 further comprising 

a timestamp facility, 
a number generator, 
said protocol including, 

establishing a server as a trusted server by a 
public key operation using the public key of the 
server to verity any message received from a 
server over the input/output port, using the 
timestamp to verify a timestamp received from 
the server and the public key of the trusted cer- 
tificatkxi authority to verify a certificate provid- 
ed by the server, and after the verificatkxis. 
generating the secret session key using a 
number supplied by the number generator, 
concatenating a timestamp provided by said 
timestamp facility with the secret session key 
and encrypting with the public key used for ver- 
ification or with a different public key of said 
trusted server the concatenated timestamp and 
secret session key. and 
sending the encrypted result to the trusted serv- 
er over the input/output port. 

38. A smart card as in claim 28 wherein the certificate 
includes a first data portion which is essential for 
verification of the certificate and a second data por- 
tion and said protocol includes splitting said first and 
second data portions, encrypting only said first data 
portfon, and sending the encrypted first data portkxi 
and an unencrypted second data portkxi to the 
sen/er. 

39. A server having a protocol for interactively engaging 
with and verifying the authenticity of a client of lim- 
ited computational capacity comprising, 

a mennory storing a private key of the private 
key/public key pair of the server and a trusted 
certification authority's public key, 
a facility for generating time-varying values, 
a processor for performing the protocol, 
said protocol including. 

receiving and processing from said client a 
message including a session key encrypt- 
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ed with the server's public key and at least 
a part of the client's certificate encrypted 
with the sesskxi key, one of said session 
key and said at least a part of the client's 
certificate being concatenated with a time- 
varying value, said processing including 
performing a private key operation on the 
message with the server's private key to re- 
cover the sesskun key, decrypting the mes- 
sage with the session key to recover at 
least part of the client's certificate, receiv- 
ing the time-varying value from the mes- 
sage and checking it with the current time- 
varying value of the facility to see that the 
client's time-varying value is proper, per- 
fonming a public key operation on the at 
least part of the client's certificate with the 
trusted certification authority's public key 
and verifying the client's certificate. 

40. A sender as in claim 39 further including in a CRL 
memory a certificate revocation list and wherein the 
step of verifying the client's certificate includes 
checking the certificate revocatkxi list for the pres- 
ence of the client's certificate. 

41. A server as in claim 40 wherein the protocol further 
includes a step of exchanging certificate revocation 
lists with the client 

42. A server as in claim 39 wherein said memory stores 
a certificate for the server's publk; key, and said 
server providing to a client, a time-varying value, the 
server's publk; key certificate or both. 

43. A server as in claim 39 wherein the message from 
the client Includes a first data portion of the client's 
certif k»te encrypted with the session key and a sec- 
ond data portion of the client's certificate whch is 
not encrypted, said protocol including decrypting 
the first data portion of the client's certificate and 
joining the decrypted first data portion with the sec- 
ond data portion. 

44. A smart card comprising a processor, a read only 
nnemory. an input/output port, and a facility for pro- 
ducing a time-varying value. 

said processor including means for producing 
a sender's public key and means for executing 
a protocol stored in said menr>ory for establish- 
ing the authenticity of the smart card to a trust- 
ed server, 

said memory having stored therein a certificate 

— for the smart card, 

said protocol including concatenating at least a 
part of the certificate with a time-varying value 
provided by said facility, encrypting the result of 
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the concatenating with the server's public key 
to form a message and sending the nnessage 
via the input/output port. 

45. A smart card as in claim 44 wherein said facility for s 
providing a time-varying value comprises a clock. 

46. A smart card as in claim 44 wherein the means for 
producing a server's public key includes receiving, 
processing and verifying a public key certificate of io 
the server provided at the input/output port during 

a transaction. 

47. A smart card as in claim 46 wherein the server's 
public key used for verifying and encrypting are dif- is 
ferent public keys of the server. 

48. A srfiart card eis in clairn 44 wherein said facility for 
providing a time-varying value comprises means for 
receiving a time-varying value via the input/output so 
port and for supplying it or a modification thereof as 

the time varying value of the snnart card. 

49. A smart card as in claim 48 wherein the means for 
producing a server's public key includes receiving 25 
and processing arKJ verifying a public key certificate 
received from a server at the input/output port. 

60. A smart card as In claim 44 wherein said certificate 

for the smart card includes structured information so 
about the smart card but no public key. 

61. A smart card as in claim 44 wherein the certificate 
includes a first data portion and a second data por- 
tbn and sakJ protocol concatenates and encrypts 35 
only the first data portkxi and the message sent via 

the input/output port includes an encrypted first data 
portkxi and an unencrypted second portion. 

62. A method for establishing the authenticity of a client 40 
in a client-server electronic transaction where a 
sender having publk; key/private key pairs and a cer- 
tification authority's public key and a client having a 
certificate signed by the certification authority are 
coupled by a commun'cations channel comprising 45 

the client. 

producing a time-varying value, concatenating 
the time-varying value with at least part of said 
certificate, encrypting the concatenated result so 
with the server's public key to produce a mes- 
sage, and sending the message to the server, 
the server, 

decry pting the message using the private key 
of thB~publk; key/private key pair recovers the ss 
time-varying value and at least part of the cli- 
ent's certificate, verifies the time-varying value 
and processes at least part of the certificate us- 




911 A2 28 

ing the certlficatton authority's public key and 
verifies it, establishing theauthenttcity of the cli- 
ent. 

53. A method as in claim 52 wherein the certificate in- 
cludes a first data portion and a second data portion 
and only the first data portion is concatenated and 
encrypted and the message sent to the server in- 
cludes an encrypted first data portion and an unen- 
crypted second data portion, said sen/er decrypting 
the first data portion and joining the decrypted first 
data portbn and the second data portion. 

54. A method as in claim 53 wherein the first data por- 
tion of the certificate comprises at least a portion of 
a digHal signature on the certificate. 

55. A method as in claim 52 wherein the client's certif- 
icate comprises structural mfomnation about the cli- 
ent but no public key. 

56. A method as in claim 55 wherein said eerver has a 
public key certificate for its public key and steps in 
the method include sending said public key certifi- 
cate to the client, said client processing the public 
key certificate to verify it and to recover the server's 
public key and using the public key in the step of 
encrypting the concatenated result. 

57. A method as in claim 56 further including said server 
sending a time-varying value to the client, said client 
using the received time-varying value for the time- 
varying value that is concatenated with at least part 
of the certificate. 

58. A method as in claim 55 further including said server 
sending a time-varying value to the client, said client 
using the received time-varying value for the time- 
varying value that is concatenated with at least part 
of the certificate. 

59. A method ae in claim 52 wherein said sender has a 
public key certificate for its public key and steps in 
the method include sending the public key certifi- 
cate to the client, said client processing. the public 
key certificate to verify it and to recover the server's 
public key and using the recovered public key in en- 
crypting at least part of the certificate concatenated 
with a time-varying value. 

60. A method as in claim 59 further including the server 
sending a time-varying value to the client, said client 
using the received time-varying value in the step of 
producing a tirrie-varying value. 



61 . A method as in claim 52 further including the sen/er 
sending a time-varying value to the client, said client 
using the received time-vaiying value for the time- 
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varying value that is concatenated with at least part 
of the certificate. 

62. A method as in claim 52 wherein establishing the 
authenticity of the client is non-interactive. 

63. A method as in claim 55 wherein establishing the 
authenticity of the client is non-interactive. 

64. A method as in claim 52 wherein said server has a 
public key certificate for its public key and steps of 
the method include sending said public key certifi- 
cate to the client, said client processing the public 
key certificate to verify it and wherein the client and 
server use a second public key/private key pair to 
encrypt/decrypt, respectively, the message. 

65. A method for determining at a verifier whether a us- 
er is authorized to perform an operation, said meth- 
od comprising the step of obtaining from said user 
a credential authorizing said user to perform said 
operatkxi. wherein 

said credential includes a digital signature by a 
credential issuing authority; 
at least data essential to verify said credential 
is transmitted from said user to said verifier 
through an encrypted communications chan- 
nel; and 

wherein the determination of authorization 
does not depend on an operation with a public 
key-belonging to said user. 

66. A method as in claim 65. wherein the credential in- 
cludes data essential for ver*rficatk>n of the creden- 
tial as well as non-essential data and only the es- 
sential data is encrypted and the non-essential data 
is sent to the verifier unencrypted. 

67. A method as in claim 66 wherein the credential in- 
cludes a f ieW confuted as a one-way f unctk>n of a 
secret value, the secret value is encrypted and sent 
to the verifier and the verifier corrputes and com- 
pares the one way functkxi of the secret value to 
the field. 

68. A methpd as in claim 66 wherein the credential in- 
cludes a root of a hash tree and a path through the 
hash tree is errcrypted and sent to the verifier 

69. A method as in claim 65 wherein the communication 
channel is encrypted with a secret key shared by 
the user and the verifier. 

70. A met hod as in claim 65 wherein the communication 
channel Is encrypted with a key established by us- 
ing a key agreement technique. 



71 . A method as in claim 65 wherein the communication 
channel is encrypted with a key established by en- 
cryption with the verifier's public key. 

s 72, A method as in claim 71 wherein the verifier's cer- 
tificate is provided to the user and the user verifies 
the certificate. 

73. A method as in claim 71 wherein the -key is estab- 
10 lished by erK;ryption with the verifier's public key 

and a rKxi-repeating value is included with the data 
essential tor verification. 

74. A method as in daim 65 wherein the communication 
channel is encrypted with the verifier's public key 
and a non-repeating value is included with the data 
essential for verification. 

76. A method as in claim 65 wherein the verifier's cer- 
20 tificate is provided to the user and the user verifies 
the certificate. 

76. A method as in claim 65 wherein the entire creden- 
tial is transmitted to the verifier through the encrypt- 

2S ed communicatkns channel. 

77. A method as In claim 65 wherein the data essential 
to verify the credential includes at least the digital 
signature. 

30 

78. A method as in claim 65 wherein the data essential 
to verify the credential includes at least a secret val- 
ue whose one-way function value is contained in the 
credential. 

35 

79. A method as in claim 65 wherein the data essential 
. to verify the credential includes at least a path 

through a hash tree whose root is contained in the 
credential. 

40 

80. A method as in claim 77 wherein the verifier checks 
the digital signature using the credential issuing au- 
thority's public key. 

45 81. A method as in claim 78 wherein the verifier com- 
putes and compares the one-way function of the se- 
cret value with the one-way function value, of the 
credential. 

so 82. A method as in claim 79 wherein the verifier checks 
the path through the hash tree using the root con- 
tained in the credential. 

83. A method as in claim.66 wherein the verifier checks 
55 the credential usingitheicredential issuing authori- 
ty's public key. 

84. A method as in claim 65 wherein the credential is 
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issued as a result of successful authentication to the 
credential issuing authorrty. 

, 85. A method as in claim 65 wherein the credential is- 
suing authority is the verifier. s 

86. A method as in claim 64 wherein the credential is- 
sued includes a field computed as a one-way func- 
tion of a secret value, the secret value is not re- 
vealed to the credential Issuing authority and these- io 
cret value is transmitted as essential data. 

87. A method as in claim 84 wherein the credential is- 
sued includes a root of a hash tree and a path 
through the hash tree is transmitted as essential da- 
ta through the encrypted communication channel 
and wherein one or more leaves of the hash tree 
are not revealed to the credential issuing authority. 

88. A method as in claim 64 wherein the determination 20 
of authorization includes a detenmination that the 
credential is not included in a credential revocation 

list. 

89. A method as in claim 65 wherein the credential in- 2S 
eludes data specifying the types of operations for 
which the user is authorized, or the time at which 

the credential expires or a list of authorized verifiers. 
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munication channel is encrypted with a secret key 
shared with the verifier or with the verifier's public 
key and a non-repeating value. 

93. A system as in claim 91 further including a non-en- 
crypted channel for transmitting between the user 
element and the verifier data which is non-essential 
data for verifying the credential- 

04. A system as in claim 93 wherein the credential in- 
cludes a field computed as a one-way function of a 
secret value and the secret value is selected, en- 
crypted and sent to the verifier as essential data and 
the protocol of the verifier causes the verifier to 
compute and compare the one way functton of the 
secret value to the field. 

95. A system as in claim 93 wherein the credential in- 
cludes a root of a hash tree and a path through the 
hash tree is selected as essential data and trans- 
mitted to the verifier. 

96. A system as in claim 93 wherein the data essential 
to verify the credential is the entire credential or the 
digital signature on the credential.ora secret- value 
whose one way function is included in the certificate 
or a path through a hash tree whose root is included 
in the credential. 



90. A method as in claim 65 wherein the credential in- 
cludes the user's public key but the user's publk; key 
is not used in the determination of authorization. 

91 . A system for determining whether a user is author- 
ized to perform an operation with a verifier, said sys- 
tem comprising: 

a user element for providing all or at least a part 
of the data included in a credential, said user 
element also provkling data essential to verify 
the credential, said credential including at least 
a digital signature by a credential Issuing au- 
thority; 

said user element having a protocol for engag- 
ing with the verifier and including a device 
which selects data for transmission to the ver- 
ifier, said data selected by the device including 
at least data essential to verify the credential; 
an encrypted communication channel respon- 
sive to the device for transmitting data between 
the user element and the verifier, and 
the verifier including a protocol for detenmining 
whether the user is authorized to perform an 
operation wherein the determination does not 
depend on the transmission of a^e^s public 
key from the user element. 

92. A system as in claim 91 wherein the encrypted com- 



97. A system as in claim 93 wherein the credential in- 
cludes data specifying the types of operations for 
which the user is authorized, or the time at which 
the credential was issued or the time at which the 
credential expires. 
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